Project modelling and management tool

ABSTRACT

The invention concerns a project management tool comprising a plurality of terminals communicating with a central server, at least one of the terminals including: means ( 11 ) for defining project models and for inserting them in a model library ( 6   a ), each project model including a list of step models, one step representing a set of tasks contributing to the achievement of the project; means ( 15 ) for defining a scenario defining links between a source model and a target model, each link being associated with a condition concerning the properties of the source model of the link; means ( 21 ) for generating projects from project models and steps from step models; and means ( 30 ) for updating and display the state of the project steps, and for generating a new step from the target model of a scenario link, when the condition associated with the link is fulfilled.

The present invention relates to a project management tool addressingnot only the requirements for planning but also the requirement formonitoring and following up projects.

Traditionally, a project is broken down into tasks which are completedin view of achieving one goal, completing the project. The completion ofthese tasks requires the involvement of resources provided by anorganisation such as a company carrying its activities in a specificbusiness field. Resources include staff members of the organisation andequipments owned by that organisation.

Generally, one can distinguish between two types of activities:activities consisting of a few large projects and activities consistingof many small projects. Large projects involve a large number ofresources dedicated to the projects during long periods of time. Smallprojects, often referred to as files, matters, cases or contracts,involve only a small number of resources that share their time betweenseveral projects at the same time.

Existing project management tools are designed to manage and plan largeprojects.

The breakdown into tasks of a large project is generally hierarchical,with tasks regrouping sub-tasks. Moreover, project tasks can be linkedby constraints of the type predecessor/successor in order to introducean order in which tasks have to be executed. Such an order is generallyrepresented in the form of GANTT charts or PERT charts.

This approach raises a first series of issues.

Project management is a macroscopic activity which does not go into thedetails of planning each hour of work, whereas project follow-up andmanagement of resource utilisation is a microscopic activity which takesinto account every hour spent. As a consequence, either one privilegesproject management with a limited number of tasks, and in this case thegranularity of tasks is insufficient for managing time spent, especiallyif the number of resources required to complete a task is high. Or oneprivileges the management of resource utilisation which implies far toomany tasks for achieving serious planning with a traditional projectmanagement tool.

Furthermore, project management focuses on a project in its entirety andin particular on a project end date. Even if milestones are introducedin order to detect potential shifts, it is frequent that the delays thatthese milestones reveal are not significant due to tasks initiallyforgotten and subsequently added to the project or tasks executed in anorder different from the order of the planned project. For that reason,it is frequent to break down large projects into smaller projects.However such a breakdown requires consolidating the smaller projectsinto the large project, which is a cumbersome, time consuming and errorprone exercise.

In addition, existing project management tools are designed to manageone project at a time, which raises other issues when a single resourcemust be allocated to several projects. It becomes difficult to estimatethe workload of a resource allocated to several projects. And thesetools which rely on the critical path method are designed to calculatethe project end date but are not adapted to calculate and monitorseveral intermediate due dates.

The traditional approach to project management raises a second series ofissues. Generally, small projects are not planned because the workloadto execute a small project cannot justify the workload to plan thisproject. The breakdown of a project into tasks allocated to resources isnevertheless necessary for monitoring and following up. Traditionalproject management tools do not permit the automatic generation ofproject data required to monitor and follow up large volumes of smallprojects, which would be too heavy or even impossible to producemanually. Moreover, some small projects last for years but only requiresmall but often recurring interventions during the life cycle of theproject. Traditional project management tools do not provide anyautomation to plan and follow-up the due dates of these recurringinterventions.

The present invention aims at solving these issues. This goal isachieved through the design of a project management tool comprising aseries of terminals communicating with a central server, characterisedin that at least one of the terminals comprises:

-   -   means to define project templates and to store them in a        template library, accessible through the central server, each        project template comprising a list of stage templates, each        stage of a project representing a set of collective works        participating in the execution of the project and achieving an        intermediate result, with a state associated with each stage;    -   means to define at least a scenario for a project template,        which is stored in the template library in relation with the        corresponding project template, each scenario defining        succession links between two nodes respectively associated with        two stage templates, that is one node at the origin of the link        and one node at the destination of the link, each link being        associated with a condition expressed as a function of        properties of the stage template associated with the node at the        origin of the link;    -   means to generate a project from a project template selected in        the template library;        each terminal comprising:    -   means to generate stages from stage templates; and    -   means of project follow-up allowing to update and visualize the        state of project stages that have been previously generated by        the means to generate stages, and of triggering the generation        of a new stage according to a stage template associated with the        node at the destination of a scenario link when a condition        associated with that link is satisfied by the properties of a        stage associated with the node at the origin of the link.

Advantageously, each stage template, part of the stage templates,comprises a list of task templates defining tasks necessary to thecompletion of a stage generated from this stage template, the projectmanagement tool comprising means to generate tasks from task templatesand means for updating and following up tasks previously generated.

Preferably, the project management tool according to the invention,comprises means to define at least one scenario for a stage template,which is stored in the template library, in relation with thecorresponding stage template, each scenario defining succession linksbetween two nodes associated respectively to task templates, that is onenode at the origin of the link and one node at the destination of thelink, each link being associated with a condition expressed as afunction of the properties of the task template associated with the nodeat the origin of the link.

According to a particularity of the invention, the project managementtool comprises means to define sub-project templates of a projecttemplate or another sub-project template, and means to define scenarioscomprising succession links between two templates among projecttemplates and sub-project templates, that is one template at the originof the link and one template at the destination of the link.

According to another particularity of the invention, the projectmanagement tool comprises means to define a terminal node in a scenario,which node is associated with an origin node in another scenario, andmeans to trigger a scenario whose origin node is associated with aterminal node of another scenario in progress, when a condition relatedto a template associated with the terminal node is validated.

According to another particularity of the invention, the projectmanagement tool comprises a stage template and this stage templatecomprises the definition of at least one planned date or one effectivedate, a stage according to such stage template including at least acorresponding planned date or effective date, each link of a scenariobeing associated with an interval and a date chosen among the planneddates and effective dates of a stage defined by its stage template andcorresponding to an anchor node of the link.

Advantageously, the anchor node of a link is the origin node of thislink.

In particular, the means to define a scenario comprise:

-   -   means to insert in a screen display panel a graphical symbol for        a node representing a stage template,    -   means to insert in said panel a graphical symbol for a link        between two node symbols, and representing a scenario link        between two stage templates, and    -   means to insert in said panel a graphical symbol for a recursive        link having for origin and destination a same node symbol,        indicating that the stage represented by the node at the origin        and destination of the link should be executed several times at        regular intervals.

Preferably, the project management tool according to the inventioncomprises means to associate a data entry form to a template, which datais specific to the objects generated from this template, and means toconvert a form defined by a user in a standard form description languageinto a form that can be used by the project management tool andassociated with this template and to the objects generated from thistemplate.

Advantageously, during the execution of a scenario, the projectmanagement tool comprises means to detect the change of a property of astage associated with a scenario node, means to find the node associatedwith that stage and the outbound links of this node, means to obtain thecondition associated with each outbound link found, means to validateeach of these conditions, means to obtain the destination node of a linkassociated with a validated condition and the stage template associatedwith the destination node obtained, and means to create a stage from thestage template thus obtained.

A preferred execution mode of the project management tool according tothe invention is described hereunder, as a non-limitative example, withreferences to the drawings enclosed, in which:

FIG. 1 is a schematic representation of a system which implements theproject management tool according to the invention;

FIGS. 2 a, 2 b and 2 c use the object oriented formalism of the UMLmethodology to describe the structure of templates and objects handledin the project management tool according to the invention;

FIGS. 3 a, 3 b, 3 c and 3 d use the object oriented formalism of the UMLmethodology to describe the structure of a scenario and its functioning;

FIG. 4 illustrates in a sequence diagram according to the UMLmethodology, the mechanisms implemented in a scenario according to theinvention;

FIG. 5 shows the main modules of a project management tool according tothe invention;

FIG. 6 shows the details of one of the main modules represented on FIG.5;

FIGS. 7 a, 7 b and 7 c are examples of scenarios created and used by theproject management tool according to the invention.

FIG. 1 represents a system which implements the project management toolaccording to the invention. This system comprises multiple terminals 2to 4 at the disposal of users from one or more organisations andconnected through a private network 5 and/or a public data network toone or more computing servers 1. Server 1 is also connected to astocking unit 6 containing a database. In such a system, terminals 2 to4 are generally constituted of desktop computers, but can also beconstituted of mobile phones or even of pocket computers and personaldata assistants. Moreover, server 1 is preferably a Web server.Obviously, network 5 can be constituted by one or more interconnectedprivate and public data networks.

In this system, server 1 makes accessible to terminals 2 to 4 thevarious functions of the project management tool, along with the datagenerated and stored by the project management tool in the stocking unit6. Obviously, access rights can be attributed to the various users ofthese terminals in view to prevent them to access certain functions ordata depending on these access rights.

In addition to the traditional breakdown of a project into sub-projectsthen into tasks, the invention introduces an intermediate level ofbreakdown between projects and tasks, called “stages” which correspondto a commitment of a set of resources allocated to the project in viewto deliver a certain result at a certain due date. For example, such acommitment corresponds to an order from a customer, a project phase, adeliverable or a billed service. One of the main properties of a stageis its milestone, which is the date when the stage objective is achievedor delivered. The effective date of the milestone is associated with aplanned date called due date of the stage, which is the date beforewhich the stage objective should be achieved or delivered, this datebeing eventually extended with grace periods that allow the stage to becompleted without compromising the project.

In this breakdown, a task is conceived as the participation of one ormore resources to this commitment. Project planning is then based on thebreakdown into stages which hides the details of the list of tasks. As aconsequence, a task can be added to a stage at any time withoutaffecting directly the planning. Following a project consists offollowing the stages and tasks which is done by the resources assignedto the project. Thanks to the invention, the stages and the project areautomatically updated by consolidating the data acquired at the tasklevel.

Furthermore, the present invention is based on the statement that, insmall projects activities, projects or matters can be categorised into asmall number of groups of similar projects. The same applies to stagesand tasks. Considering this statement, the invention introduces thenotion of object template, an object being a project, a stage or a task,a template comprising all the common characteristics of objects in thesame group of similar objects.

The common characteristics of a group of similar projects categorised ina project template comprise in particular scenarios that allow thereproduction of recurring behaviours in projects derived from thesetemplates.

The project management tool according to the invention is implemented intwo phases: a modelling phase for designing templates and a productionphase for managing objects created from these templates.

Modelling templates consists on the one hand of identifying thedifferent activities or project types in the organisation, andoptionally arranging these project templates according to a hierarchicalstructure by identifying templates of “sub-projects”, and on the otherhand of identifying the stage templates, task templates and resourcetypes that are involved in the course of those projects managed by theorganisation.

According to the invention, a project or sub-project template comprises:

-   -   an optional list of sub-project templates and rules for creating        sub-projects according to these templates,    -   a list of properties for the project template, to be filled in        forms that are specific to this template,    -   a list of stage templates and rules for creating stages        according to these templates,    -   and possibly scenarios of sub-projects and stages for specifying        a sequence of sub-projects and stages in the project template.

According to the invention, a stage template comprises:

-   -   a list of properties for the stage template, to be filled in        forms that are specific to the stage template, including a set        of states and planned intervals between two states,    -   an ordered or unordered list of task templates and rules for        creating tasks according to these templates,    -   and possibly scenarios of tasks for specifying sequences of        tasks in the stage template,

Because stages have variable execution durations and because it is notgood practice to wait until the last minute to worry about theirprogress, the project management tool according to the inventionprovides the ability to monitor the state of a stage at any time and tosend alerts when a stage is delayed or when a due date is passed. Inthis respect, stage templates provide the ability to predefine thedevelopment of a stage generated from a stage template, including thedates that have to be monitored from the creation of the stage until itscompletion. Each stage is associated with two series of dates:

-   -   planned dates which are defined and recorded at the creation of        the stage, and    -   effective dates which are recorded during the course of the        stage life.

If during the course of the stage life, an effective date is recordedafter the corresponding planned date, the stage is deemed late.

The due date and the effective date of the stage milestone are apart inthe planning and completion of a stage. Indeed, let us take the exampleof a “contract signature”. This stage comprises a certain number oftasks before (preparing the contract) and after (registering andinvoicing the contract) the effective date of the signature. Theeffective date of the signature of a contract is the effective date ofthe milestone of the corresponding stage “contract signature”. The duedate is the corresponding planned date.

On the due date, if the effective date of the stage milestone is notrecorded or recorded with a subsequent date, the stage is deemed passeddue.

As a non-limitative example, the dates and states presented in the tablebelow are considered for stage monitoring and follow-up. Planned datesEffective dates State Date planned for decision Decision date DecidedDate planned for start Start date Started Date planned for completionCompletion date Completed

By default, a stage is created in project. In this state, the stage iswaiting for a decision, which can take the form of a customer order, aninternal decision or an external event. Then the stage is considereddecided when its execution has been confirmed. The stage state evolvesinto started when the execution of the stage has begun. Finally, thestage gets into a completed state, unless it has been abandoned.

A stage template includes the definition of durations for calculatingplanned dates where the duration defines the period between a planneddate and the due date of the stage milestone. As soon as the due date ofa stage created from a template is defined, the planned dates areautomatically calculated according to the durations defined in thetemplate. Stage template Stage Calculation Duration from Planned datefor Due date - decision to due date decision = Duration from decision todue date Duration from Planned date for Due date - start to due datestart = Duration from start to due date Duration from completion toPlanned date for Due date - due date completion = Duration fromcompletion to due date

According to the invention, a task template comprises:

-   -   a planned workload and duration necessary to complete the task,    -   a list of resource types required to complete the task according        to the template,    -   and possibly an ordering number.

In the following description, an “object” designates a project, a stage,a task or a resource and a “template” designates a project template, astage template, a task template or a resource type.

FIG. 2 a uses the object oriented formalism of the UML (UnifiedModelling Language) methodology to describe the relations between thevarious types of templates and objects. This figure shows various blocksrepresenting classes and divided in 3 boxes: a first box (starting atthe top) with the name of the class, a second box with the list ofattributes of the class and a third box with the list of methods of theclass. The list of attributes contains various properties which definethe state of an object derived from that class, whereas the methods arefunctions and procedures that the class can execute.

This figure comprises blocks marked “Template” and “Object” whichidentify two categories of blocks defined by the links represented witha triangle. Thus the block entitled “Template” is linked to blocksentitled “Project Template”, “Stage Template” and “Task Template”whereas the block entitled “Object” is linked to blocks entitled“Project”, “Stage” and “Task”. This representation simply indicates thatthe category “Template” groups project templates, stage templates andtask templates, and that the category “Object” groups projects, stagesand tasks.

Templates and objects as such are abstract. Only the projects andproject templates, stages and stage templates, tasks and task templateshave effectively persistent occurrences in the system.

Then the blocks entitled “Project Template”, “Stage Template” and “TaskTemplate” are related with links which have a diamond at one end. Thisrepresentation indicates that project templates aggregate stagetemplates which aggregate task templates. A task template is necessarilycontained in a stage template and a stage template is necessarilycontained in a project template. Blocks entitled “Project”, “Stage” and“Task” are related in the same way. This means that projects aggregatestages which aggregate tasks. A task is necessarily contained in a stageand a stage is necessarily contained in a project. The block entitled“Template” has among others a method called “createObjectFromTemplate”which permits to generate an object according to a template. Theintroduction of attributes and methods in a block that represents acategory implicitly specifies that all the blocks derived from thiscategory inherit these attributes and methods.

The block entitled “Object” has a method called “getTemplate” whichenables each object to keep track of the template that has been used tocreate it and thus to retrieve it as and when needed.

Each link which has a diamond at one end is associated with numbers “1”and series of numbers “0 . . . n” respectively at the source block anddestination block of the link. The diamond on the side of the sourceblock of the link indicates that the source block aggregates thedestination block, the life of which depends on the source block, forexample the deletion of a project entails the deletion of the stageswhich depend on it. Numbers mean that the source block of the linkcontains between 0 and n occurrences of the destination block of thelink, for example a project contains between 0 and n stages. At theopposite, the destination block of a link belongs to one and only onesource block of that link, for example a stage belongs to one and onlyone project.

Moreover, the blocks entitled “Project Template”, “Stage Template” and“Task Template” are related by simple links to the blocks entitledrespectively “Project”, “Stage” and “Task”. The ends of these simplelinks are associated with series of numbers “0 . . . 1” and “0 . . . n”.This means for example that a project template can be related to one ormore projects. The absence of a diamond shape at the end of the linkmeans that the destruction of one of the two blocks does not entail thedestruction of the other block. In fact, these links correspond to the“getTemplate” method for each of the blocks entitled “Project”, “Stage”and “Task”.

The various planned dates and effective dates of a stage mentioned hereabove, can initially be considered as stage properties. To make thingssimple here, these dates are handled as attributes or properties of thestage object, providing these dates are shared among stages.

FIG. 2 b uses the same UML formalism to describe another view of therelations existing between the various types of models and objects. Thispresentation reveals a hierarchical organisation of project templatesand templates by introducing the abstract notions of collective work andcollective work template which regroup respectively projects and stageson the one hand and project templates and stage templates on the otherhand. Moreover, to model that a project can contain other projects,called sub-projects, projects aggregate collective works, which areprojects or sub-projects and stages. Likewise, project templatesaggregate collective work templates, which are project or sub-projecttemplates and stage templates.

These hierarchies can be generalised on objects and templates,especially for a breakdown of tasks into elementary tasks and groupingtasks on the one hand and a breakdown of task templates into elementarytask templates and grouping task templates on the other hand.

FIG. 2 c details the design of templates and objects. A template definesa set of template properties with default values. A method called“createObjectFromTemplate” creates an object and copies for this objectthe whole set of template properties with their default values intoobject properties. Some template properties may eventually betransformed through the execution of the “createObjectFromTemplate”method, for example template properties expressed as durations can becomputed into object properties expressed as dates. The values of objectproperties can then be modified independently from the default values oftemplate properties.

According to the invention, the stages of a project can be linkedtogether with one or more scenarios of successive stages, modelling thesequence of stages necessary to complete the project. In particular,scenarios permit to automatically generate the stages of the projectdepending on conditions which are functions of the properties andprogress status of other stages in the project.

A scenario is an automaton which automatically creates objects from thetemplates specified in the scenario as and when they are necessary. Ascenario is a set of nodes and links. The nodes represent the templatesthat have to be used to create the objects according to the scenario.Note that the same template can be referenced by several nodes of a samescenario. Such an automaton can apply to projects and sub-projects aswell as to stages and tasks.

A scenario of stages is made of stage templates symbolised by nodesconnected with links which represent a time span between a stagetemplate at the origin and a stage template at the destination of thelink. Each link designates accordingly:

-   -   a source node or origin of the link, associated to an origin        stage template;    -   a destination node of the link, associated to a destination        stage template;    -   a type of anchor date among the planned dates and effective        dates of an origin stage: (planned) decision date, (planned)        start date, (planned) completion date, due date and effective        date of the stage milestone;    -   a duration expressed in days, months and years between the        anchor date of the source of the link and the due date of the        stage associated to the destination node of the link;    -   and possibly, a condition expressed as a function of the stage        template properties. This condition can be advantageously        implemented as a script interpreted by the system.

In the case where the origin and destination nodes of a link areidentical, the link is said to be recurring. When these nodes aredifferent, the link is not recurring.

FIG. 3 a details the specification of scenarios. In this figure, the“link” block is abstract. In other words, only recurring links andnon-recurring links actually have occurrences persisting in the system.A scenario comprises an origin node which is the only node which is nota destination for any link.

Note that the diagram of FIG. 3a can easily be modified to allowchaining scenarios, for example by introducing a sub-class called“terminal node” of the class “node” and thus specify a node which wouldnot be the origin of any link in the scenario, but would be associatedto the origin node of another scenario.

FIG. 3 b describes the links between scenarios and objects. Objects, andin particular projects, stages and tasks, are not necessarilyautomatically created b scenarios. They can be created manually on an adhoc basis according to the templates. In the case where an object hasbeen generated with a scenario, this object keeps a reference to thenode, and to the scenario which has permitted its creation. Thisreference is used to determine the next object to generate according tothe links. It is obtained by using the “getNode” method on the object.

By extension, one calls scenario node template the template associatedwith said node, which is returned as a result of executing the“getTemplate” method on the node. One calls origin template,respectively destination template, the template associated with the nodeat the origin of a scenario link, respectively at the destination of ascenario link. One calls origin object, respectively destination object,an object generated with a scenario according to an origin template,respectively a destination template.

Classes derived from class “Object” which use scenario for automaticgeneration, in particular project, stage and task, implement the“generateWithScenario” method (see also FIGS. 2 a and 2 c). When callingthis method, an object created from a scenario node obtains the saidnode by calling the “getNode” method. This node is at the origin of thelink considered for generation. The “getOutboundLinks” method of theorigin node returns a collection of outbound links. The“getDestinationNode” method called on each outbound link enables gettinga collection of destination nodes of the links. The “getTemplate” methodcalled on each destination node of every link returns a collection ofcorresponding templates, in order to create eventually the correspondingdestination objects by calling the “createObjectFromTemplate” method onevery template.

It is possible to control the existence of a destination object beforegenerating it according to a destination template defined on a link, inorder not to duplicate the same generation. For this purpose, eachobject keeps a reference of its successors. Each time the generation ofa destination object is triggered following a link, the existence of asuccessive object which would reference the destination node of thatlink has to be checked in order to avoid repeating a generation whichhas already occurred.

FIG. 3 c describes the implementation of a condition for generating adestination object following a scenario link. An origin templatecontains a set of predefined conditions for generating destinationobjects following a scenario link. A link connected to a nodereferencing this origin template may designate a condition of this setfor generating a destination object following this link. The conditionis checked using the “isConditionValidated” method, which is anexpression of the properties of a same template and which returns aBoolean. This method takes the origin object as a parameter and uses thevalues of the properties of this origin object which correspond to thetemplate properties designated in the expression for validating thecondition. The destination object is created according to the scenarioonly if the condition is validated.

As an example, we consider a scenario comprising at least two nodes anda link. The first stage template corresponding to the first node, at theorigin of the link, is a “contract signature” and the second stagetemplate corresponding to the second node, at the destination of thelink, is a “credit check”. The stage template called “contractsignature” comprises a template property of type currency and named“amount”. The condition associated to the link is “amount above10,000.00” which means that the credit check is only performed if theamount is above 10,000.00. Stage “signature of Mr. Bloggs' contract” isa specific instance of the stage template “contract signature”. If theobject property corresponding to “amount” has a value of 18,000.00, thecondition is validated and the stage of credit check for Mr. Bloggs isgenerated for its execution.

At this level, generating the object following the link is triggered byan action in the user interface. Preferably, this generation istriggered by a system event, for example when object property “amount”is valued.

For that purpose, a notification mechanism can be considered and used tobuild an event model. Modifying an object property value by using the“setValue” method systematically triggers an event notification raisedby the object from which depends the object property, by a call to the“propertychanged” method of that object.

FIG. 4 shows a sequence diagram according to the UML methodology of ageneration following a scenario with such a condition and events. Eachtime a new value is assigned to an object property, the object isnotified by a call to its “propertyChanged” method. The object uses its“getNode” method to find the scenario and node which have permitted itscreation. If such a node does not exist, the object is not part of theexecution of a scenario and the sequence does not apply. If such a nodeexists, the object calls the “getOutboundLinks” method of this node toobtain a collection of links that originate from this node. For each ofthe outbound links, a call to the “getcondition” method returns thecondition which applies and which is validated through a call to the“isConditionValidated” method. If the condition is not validated, thesequence evaluates the next link in the collection. If the condition isvalidated, the object obtains the destination node of the link bycalling the “getDestinationNode” method of the outbound link, and theassociated template by calling the “getTemplate” method of thedestination node. Finally, a call to the “createObjectFromTemplate”method of the destination template permits the creation of thedestination object. The sequence moves to the next link in thecollection of outbound links until it reaches the last element of thecollection.

FIG. 3 d describes a specific application of scenarios according to theinvention. The scenario automatically generates stages and positionsthem over time. To do so, every stage comprises the following objectproperties: “plannedStart”, “effectiveStart”, “plannedCompletion”,“effectiveCompletion” (see also FIGS. 2 a and 2 b) from which thefollowing states can be deduced:

-   -   “In project” or “Not started” if both the effective start date        and the effective completion date have not been provided,    -   “Started” or “Not completed” if the effective start date has        been provided, but not the effective completion date,    -   “Completed” if the effective completion date has been provided.

The scenario is used to compute the planned completion date(“plannedCompletion”) of a destination stage (“destinationStage”) of alink using a function of the interval (“intervalBetweenStages”) betweenthe origin stage (“originStage”) and destination stage of the link. Thestage template (“destinationStageTemplate”) provides the ability todeduce the planned start date (“plannedStart”) from the planned duration(“plannedDuration”) of the destination stage template. In a firstvariant, the following assertions are made:destinationStage.plannedCompletion=originStage.effectiveCompletion+link.intervalBetweenStagesanddestinationStage.plannedStart=destinationStage.plannedCompletion−destinationStageTemplate.plannedDuration

In a second variant, the link designates an anchor node for calculationpurpose. One calls anchor stage template the stage template designatedby the anchor node of a scenario link and anchor stage (“anchorStage”)the corresponding stage. Calculation becomes:destinationStage.plannedCompletion=anchorStage.effectiveCompletion+link.intervalBetweenStagesanddestinationStage.plannedStart=destinationStage.plannedCompletion−destinationStageTemplate.plannedDuration

Note that the first variant is a specific occurrence of the secondvariant where origin node and anchor node are identical.

In a third variant, the condition which applies to the link is“anchorStage.effectiveCompletion is valued (not null)”. By extension,the generation of the destination stage is executed after notificationof the change of value of the “effectiveCompletion” object property whenit is provided.

In a fourth variant, the date of the anchor stage on which thecalculation is based, is specified in the link with a “chosendate” whichcan reference any of the object properties including “plannedStart”,“effectiveStart”, “plannedCompletion” or “effectiveCompletion” and thecalculations become:destinationStage.plannedCompletion=anchorStage.chosenDate+link.intervalBetweenStagesanddestinationStage.plannedStart=destinationStage.plannedCompletion−destinationStageTemplate.plannedDuration

It is possible to consider a whole series of dates as object propertiesof a stage including order date, planning date and invoice date.

For the implementation of all the mechanisms that have been describedhereinabove, the project management tool according to the inventioncomprises three main modules (see FIG. 5): a module for managingtemplates 10, a module for managing objects 20 and a module forfollowing up and monitoring objects 30.

The module for managing templates 10 comprises a module for creating andupdating templates 11, in particular project templates, stage templates,task templates and resource types, which are arranged in a templatelibrary 6 a stored in a stocking unit 6, and a module 12 for searchingfor these templates. The module for managing objects 20 comprises amodule 21 for creating and updating objects, in particular projects,stages, tasks and resources, in compliance with the templates stored inthe library 6 a, these objects being arranged in a database 6 b alsostored in the stocking unit 6, and a module 22 for searching for theseobjects.

The module for monitoring and following up objects 30 is designed forlisting objects according to criteria to be entered, in particular thestate of these objects at a certain date. This module comprises a modulefor monitoring and following up stages 31, designed for listing stages,and a module for monitoring and following up tasks 32, designed forlisting tasks, and in particular for a given resource and a given periodof time. The module for following up tasks can take the form of anelectronic timesheet or an electronic personal diary.

As shown in details on FIG. 6, the module for creating and updatingtemplates 11 comprises a function 13 for defining project templates, afunction 16 for creating custom entry forms, a function 14 for definingstage templates, a function 15 for defining scenarios, a function 18 fordefining tasks templates, and a function 17 for defining resource types.

The function for defining project templates 13 permits the entry ofgeneral information related to the project template like a title and adescription. This function implements sub-project templates to allow thebreak-down of a project template into several sub-project templates. Forthis purpose, the function for defining project templates permitsspecifying whether the new project template to create is a “root”project template of the hierarchy or a sub-project template which needsto be related to an existing project template called, parent projecttemplate. If the new project template to create is a sub-projecttemplate, function 13 permits specifying whether the correspondingsub-project should be created automatically with the parent projectcorresponding to the parent project template. Function 13 also permitsdefining a minimum and a maximum of occurrences of sub-projects within aparent project.

The function for creating custom forms 16 provides the ability to uploadinto the template library 6 a one or more new forms defined in astandard language like HTML, to select an uploaded form and to assign itto a template. Advantageously, one can rely on any specific editorcompatible with this language to create a form that can benefit theproject management tool according to the invention. Function 16 alsopermits parsing the fields in the HTML form, and creating in thetemplate library 6 a the template properties for the template that usesthe form.

These template properties are stored as a database table in the templatelibrary 6 a as described below: Field Type Size Description Id Long IntN/A Property Identifier TemplateId Long Int N/A Template Identifier OrObjectId Name Varchar 50 Property Name Datatype Varchar 20 PropertyType: Number, Text, Date, Boolean, etc. Value Varchar 7000 Value

Possibly, specific attributes can be added to the HTML tags to validatethe type of entries in text boxes. In HTML a textbox is defined by thefollowing tag:

-   -   <input type=“text” name=“T1” size=”20”>    -   which can be enriched with the data-type attribute for type        validation, in the following manner:    -   <input type=“text” name=“T1” size=“20” data-type=“date”>    -   in order to control effectively the type of data entries allowed        in the textbox. Other attributes can be considered on the same        principle, especially for validating the domain of data entries.

Function 16 also permits interpreting a form and displaying it with thecorresponding data read from the above mentioned database table. Thedocument object model of a browser gives the ability to read and writedata in the form fields of an HTML page as rendered by the browser.

Function 14 permits defining the stage templates that belong to aproject template. In particular, this function permits the entry ofgeneral information related to the stage template like a title and adescription. This function calls function 16 to assign one or morecustom forms for data entries related to a stage according to thistemplate. It is also designed for defining the planned durations of astage template, and eventually for specifying a list of tasks that haveto be completed to execute the stage by calling the function 18 of tasktemplate definition.

Function 18 allows to breakdown a stage template into a list of tasktemplates and for each task template added to the list, to specify aname, a description, a planned workload and planned duration necessaryfor completing the corresponding task. To allocate one or more types ofresources to a task template, function 18 calls function 17.

Apart from assigning resource types to task templates, function 17allows the constitution of a catalogue of resource types available inthe system for executing projects. Resource types correspond to theroles that can be played by a resource in a project, for example projectmanager, engineer, consultant, technician or assistant.

Function 15 for scenario definition permits specifying a name, adescription and optionally a period of validity of the scenario, andalso to draw a graphical representation of the scenario in a drawingpanel, with nodes and links between nodes. The addition of a new nodeopens a window for selecting a stage template among the list of stagetemplates relevant to the current project template, and the addition ofa new link between two nodes requires the entry of an anchor date, aninterval from the anchor date and a condition to execute the link. Thisfunction also allows the addition of recurring links that are linkswhere the origin node and the destination node are identical.

FIGS. 7 a, 7 b and 7 c show examples of scenarios.

FIG. 7 a illustrates a scenario for selling appliances withoutmaintenance. This scenario comprises a first stage represented by anorigin node 51 of the scenario, corresponding to the signature of thesale agreement by a customer, a stage represented by a second node 53,corresponding to the delivery of the appliance, and a stage representedby a third node 55, corresponding to the installation of the appliance.The first and second nodes are connected by a link associated with aninterval 52, which indicates that the delivery of the appliance to thecustomer should be completed within 16 days from contract signature. Thesecond and third nodes are also connected by a link associated with aduration 54, which indicates that the installation of the applianceshould be completed within 16 days from its delivery. Both links 52 and54 have an anchor date which is not represented. This anchor date is thecompletion date of the stage corresponding to the node at the origin ofthe link, because it is not possible to deliver without signature and toinstall without delivery. FIG. 7 b illustrates a scenario for sellingappliances with maintenance, where the agreement is renewable annuallyand provides for two annual preventive visits. In addition to stages 51,53, 55 and links 52, 54 of the scenario for selling appliances withoutmaintenance, as shown on FIG. 7 a, this scenario comprises a first stage57 of preventive maintenance visit, triggered 3 months after contractsignature (link 56) and a second stage 59 of preventive visit triggered6 months (link 58) after the first stage of preventive visit 57. Forboth links 56 and 58, the anchor date which is not represented, is thedue date of the stage at the origin of the link, because even if thefirst visit 57 is delayed or cancelled, the second visit has to occuraccording to the signed contract terms.

According to a variant of execution of the invention described above asscenario chains, there is a benefit in regrouping the successivepreventive visits in an independent scenario and to chain the signature51 and the renewal 61 to this independent scenario. Likewise, there isno need to duplicate the structure made of nodes 57 and 59 connected bylink 58.

Because the maintenance agreement is renewable every year, thecorresponding scenario comprises a stage 61 of renewal, connected to thestage 51 of signature by a link 60 with a period of one year, and thestage of renewal is connected to itself by a recurring link 62 also witha period of one year. Stage 61 is also connected (link 56) to a firststage 57 of preventive visit, which is connected (link 58) to a secondpreventive visit 59. The anchor date for link 60 is the date ofmilestone completion (signature date) and the anchor date for link 62 isthe renewal due date, in order to ensure a due date which alwayscorresponds to the anniversary of the signature date.

FIG. 7 c illustrates a scenario for renting appliances, where thecontract has a duration of three years, including two annual preventivemaintenance visits. This scenario also comprises an origin node 51corresponding to contract signature and nodes 53 and 55 representingrespectively the stages of delivery and installation, these three nodesbeing connected by links 52 and 54. Moreover, stage 55 of installationis connected by a link 56 with an interval of 3 months to a first stageof preventive visit 57, which is connected by a link 58 with an intervalof 6 months to a second stage of preventive visit 59. The payment of theannual balance of rents by customer (stage 64), a year after thesignature stage 51 (link 63), is followed 3 months later (link 56), bytwo stages of preventive visit 56 and 57, separated by a time intervalof 6 months (link 58). These stages are repeated during the third yearof the contract (link 65 between stages 64 and 66).

Because the contract can be renewed, the stage for annual payment 66 isconnected by a link 67 with an interval of one year to a stage ofrenewal 68. The anchor dates can be deduced from the precedingexplanations and are not detailed.

It is interesting to note that the “sale/rental of appliances” projecttemplate which comprises the three scenarios represented on FIGS. 7 a, 7b and 7 c, and the stage templates involved in these scenarios, alsocomprises a supplementary stage template for handling curative visits,which does not participate in any scenario. Curative visits aretriggered at any time by customers when their apparel is faulty.

Function 15 for defining scenarios also permits to copy, paste andmodify an existing scenario in order to create a new one. Likewise,functions 13 and 14 for defining project and stage templates permit tocopy, paste and modify an existing project or stage template to create anew one.

Module 21 for creating and updating objects is designed for presentingto a user a list of all the project templates available in the templatelibrary 6 a, these templates being advantageously grouped by businessfield to make selection easier.

Following user selection of a project template, this module creates anew project object in the database of objects 6 b and displays a windowon a user's terminal screen, comprising a panel for entering generalinformation and panels for the custom forms corresponding to theselected project template.

Once a project has been created according to a template, the followingphase consists in initiating a scenario. In this respect, module 21 forcreating and updating objects gives access to the list of stagetemplates and scenarios of the project template used to create theproject. It is possible to create a first stage from a stage template ofthe list. It is also possible to designate a scenario in the list andlet it create the first stage from the template corresponding to itsorigin node.

In both cases, it is mandatory to enter the due date of the stage tocreate.

Module 21 creates a new stage object in the database of objects 6 b anddisplays a window on a user's terminal screen, comprising a panel forentering general information, planned dates calculated from durationsdefined in the stage template, effective dates to be entered, and panelsfor the custom forms corresponding to the selected stage template.

Optionally, the list of tasks of a stage is generated according to thelist of task templates included in the corresponding stage template.Preferably, this generation is executed from a user command orautomatically when a stage passes a predefined state. For example, it isuseless to break down an annual renewal into tasks a year before it isdue.

Module 31 for following up stages returns a list of stages due within aperiod and which have reached a certain state at a certain date, forexample due in the next 6 months and not yet decided. As in module 22for searching and updating objects, module 31 for following stagespermits to record effective dates and state changes of stages.

A user can resort to module 22 for searching and updating objects ormodule 31 for allocating resources to each task of a stage. For thispurpose, the user has to select, for each task of the task list of astage, the name of one or more resources, generally among the staffmembers of the organisation which hosts the system, within the list ofresources of the database of objects 6 b, corresponding to the resourcetypes assigned to the tasks templates of the stage template.

A resource can use module 32 for following tasks, in view to record theprogress of its work. The module for following tasks lists all the tasksallocated to this resource and which depend from stages which have beendecided but not yet completed at a certain date. Advantageously, themodule 32 for following tasks displays a timesheet, that is a table withtasks from the list as rows and days within a relevant period ascolumns, where the period can be the current week or the current month.Table cells at the intersection of rows and columns contain fields forentering time spans expressed in hours and minutes corresponding to thetime spent by a resource to execute partially or fully the task in thecorresponding day. Time spans are only durations, and the sum of themfor all the resources of a same task constitutes the workload necessaryto complete that task. The task duration is determined by the periodthat starts with the first time span and end with the last time spanspent by any resource on the said task.

Module 20 for managing objects and module 30 for following objectsprovide the ability to mark tasks complete. Stage states areadvantageously calculated from task states:

-   -   A stage is started when at least one of its tasks is started and        the starting date of a stage is the date of the first time span        worked by a resource on any task of that stage;    -   A stage is completed when all its tasks are completed and the        completion date of that stage is the date of the latest time        span worked by a resource on any task of that stage;

Any data entered by a user or computed following the project templates,stage templates and task templates are inserted by modules 20 and 30into the database of objects 6 b, in “stage” and “task” objects inrelation to the corresponding “project” object.

Module 20 for managing objects permits the modification of calculatedstart dates and completion dates of stages, especially to take intoaccount non recorded works.

Changes in stage states, determined by changes in their property values,trigger a call to module 21 for creating and updating objects, in orderto progress the scenario previously initiated on the project. If thescenario identifies an outbound link for the current stage and if thecurrent stage comprises the required data for creating the destinationobject of that link, the said destination object is generated with a duedate which is function of the anchor date and of the interval, definedby the link, between said anchor date in the origin stage and the duedate of the destination stage.

Depending on the number of outbound links, the corresponding destinationstages are generated in the database of objects 6 b. Each newdestination stage is listed in the follow-up of stages and the processdescribed here above is reproduced for the new stage. In the examplerepresented on FIG. 7 b, the completion of the “signature” stagetriggers the generation of the “Delivery”, “Preventive Visit” and“Renewal” stages according to the corresponding stage templates.

And so on until the very last stage of a scenario. When this very laststage is completed, the project is eventually considered as completed.

Module 10 for modelling projects may only be accessible from a limitednumber of terminals 2 to 4, and more particularly only accessible to keyemployees of the organisation, whereas module 20 for managing objectsand module 30 for monitoring and following up objects are accessiblefrom every terminal, to let any resource of the organisation report ontheir work and insert into the database of objects 6 b data related toprojects, stages and tasks that they are executing.

Advantageously, the system comprises means to print details and lists ofobjects and templates.

1. Project management tool comprising a series of terminals (2, 3, 4)communicating with a central server (1), characterised in that at leastone of the terminals comprises: means (11) to define project templatesand to store them in a template library (6 a), accessible through thecentral server (1), each project template comprising a list of stagetemplates, each stage of a project representing a set of collectiveworks participating in the execution of the project and achieving anintermediate result, with a state associated with each stage; means (15)to define at least a scenario for a project template, which is stored inthe template library (6 a) in relation with the corresponding projecttemplate, each scenario defining succession links (52, 54) between twonodes (51, 53) respectively associated with two stage templates, that isone node (51) at the origin of the link and one node (53) at thedestination of the link, each link being associated with a conditionexpressed as a function of properties of the stage template associatedwith the node at the origin of the link; means (21) to generate aproject from a project template selected in the template library; eachterminal comprising: means (21) to generate stages from stage templates;and means (30) of project follow-up allowing to update and visualize thestate of project stages that have been previously generated by the meansto generate stages, and of triggering the generation of a new stageaccording to a stage template associated with the node at thedestination of a scenario link when a condition associated with thatlink is satisfied by the properties of a stage associated with the nodeat the origin of the link.
 2. Project management tool according to claim1, characterised in that each stage template, from at least a part ofthe stage templates, comprises a list of task templates defining tasksnecessary to the completion of a stage generated from this stagetemplate, the project management tool comprising means (21) to generatetasks from task templates and means (32) for updating and following uptasks previously generated.
 3. Project management tool according toclaim 2, characterised in that it comprises means (15) to define atleast one scenario for a stage template, which is stored in the templatelibrary in relation with the corresponding stage template, each scenariodefining succession links between two nodes respectively associated totask templates, that is one node at the origin of the link and one nodeat the destination of the link, each link being associated with acondition expressed as a function of the properties of the task templateassociated with the node at the origin of the link.
 4. Projectmanagement tool according to claim 1, characterised in that it comprisesmeans (11) to define sub-project templates of a project template oranother sub-project template, and means (15) to define scenarioscomprising succession links between two templates among projecttemplates and sub-project templates, that is one template at the originof the link and one template at the destination of the link.
 5. Projectmanagement tool according to claim 1, characterised in that it comprisesmeans to define a terminal node in a scenario, which node is associatedwith an origin node in another scenario, and means to trigger a scenariowhose origin node is associated with a terminal node of another scenarioin progress, when a condition related to a template associated with theterminal node is validated.
 6. Project management tool according toclaim 1, characterised in that it comprises a stage template and thisstage template comprises the definition of at least one planned date orone effective date, a stage according to such stage template includingat least a corresponding planned date or effective date, each link of ascenario being associated with an interval and a date chosen among theplanned dates and effective dates of a stage defined by its stagetemplate and corresponding to an anchor node of the link.
 7. Projectmanagement tool according to claim 6, characterised in that the anchornode of a link is the origin node of this link.
 8. Project managementtool according to claim 1, characterised in that the means to define ascenario comprise: means to insert in a screen display panel a graphicalsymbol for a node representing a stage template, means to insert in saidpanel a graphical symbol for a link between two node symbols, andrepresenting a scenario link between two stage templates, and means toinsert in said panel a graphical symbol for a recursive link having fororigin and destination a same node symbol, indicating that the stagerepresented by the node at the origin and destination of the link shouldbe executed several times at regular intervals.
 9. Project managementtool according to claim 1, characterised in that it comprises means (16)to associate a data entry form to a template, which data is specific tothe object generated from this template, and means to convert a formdefined by a user in a standard form description language into a formthat can be used by the project management tool and associated with thistemplate and to the objects generated from this template.
 10. Projectmanagement tool according to claim 1, characterised in that during theexecution of a scenario, the project management tool comprises means todetect the change of a property of a stage associated with a scenarionode, means to find the node associated with that stage and the outboundlinks of this node, means to obtain the condition associated with eachoutbound link found, means to validate each of these conditions, meansto obtain the destination node of a link associated with a validatedcondition and the stage template associated with the destination nodeobtained, and means to create a stage from the stage template thusobtained.